Verifying transaction context data at wallet service provider

ABSTRACT

A first message is received at a wallet service provider. The first message contains transaction detail and transaction context data. A second message is also received at the wallet service provider. The second message contains a copy of the transaction detail data and a copy of the transaction context data. The wallet service provider may verify that the data copies match the original data. One of the messages may be received from a payment-enabled mobile device. The other message may originate from a merchant.

CROSS REFERENCE TO RELATED APPLICATION

This application claims the benefit of U.S. Provisional PatentApplication No. 61/948,197 filed on Mar. 5, 2014, the contents of whichare hereby incorporated by reference for all purposes.

BACKGROUND

Payment cards such as credit cards and debit cards are in widespreaduse. In some environments, payment cards in the form of magnetic stripecards prevail in terms of popularity. With mag stripe cards, the paymentcard account number may be read from the card at the point of sale by amagnetic stripe reader, and then submitted with a transactionauthorization request to the account issuer via the payment network.

In other environments, it is more common to use so-called “contactless”payment cards. With contactless payment cards, the payment card accountnumber is stored in an integrated circuit (IC) within the card, and isread by short-range radio communication between the card and thecontactless reader component of a point of sale (POS) terminal Withenhancements that have occurred to mobile phones, including smartphones,the capability has been added to perform NFC (near field communication)communications to enable so-called “contactless” payment cards to bedigitized into these consumer devices. These mobile devices utilize asecure element (SE) to store the payment card account number andassociated data, keys and Personal Identification Number (PIN) to enablethe consumer to perform a payment transaction using the NFC short-rangeradio communications provided by the mobile device and the contactlessreader component of a POS terminal.

In still other environments, so-called “contact” payment IC cards areplaced in point of sale readers that can read the payment card accountnumber from the card IC via direct conductive contacts provided on theface of the card.

As recent events have underlined, security of payment card accountnumbers can be a significant issue. Large scale data breaches at themerchant level have occurred and have compromised many cardholders'payment card account numbers. Efforts are ongoing to reduce the risk oftheft and misuse of payment card account numbers.

BRIEF DESCRIPTION OF THE DRAWINGS

Features and advantages of some embodiments of the present invention,and the manner in which the same are accomplished, will become morereadily apparent upon consideration of the following detaileddescription of the invention taken in conjunction with the accompanyingdrawings, which illustrate preferred and exemplary embodiments and whichare not necessarily drawn to scale, wherein:

FIG. 1 is a block diagram that illustrates a conventional paymentsystem.

FIG. 2 is a block diagram that illustrates a payment system provided inaccordance with aspects of the present invention.

FIG. 3 is a block diagram that illustrates a payment-enabled mobiletelephone provided in accordance with aspects of the present inventionand that may be used in connection with the system of FIG. 2.

FIG. 4 is a block diagram that illustrates a point of sale (POS)terminal provided in accordance with aspects of the present inventionand that may be part of the system of FIG. 2.

FIG. 5 is a block diagram that illustrates a computer system that may beoperated by a wallet service provider as part of the system of FIG. 2and in accordance with aspects of the present invention.

FIG. 6 schematically represents enrollment of a payment card accountwith a wallet service provider that participates in the system of FIG.2.

FIG. 7 schematically illustrates software and functional aspects of thepayment-enabled mobile telephone of FIG. 3.

FIG. 8 illustrates additional details of software aspects of thepayment-enabled mobile telephone of FIG. 3.

FIG. 9 illustrates still further details of software aspects of thepayment-enabled mobile telephone of FIG. 3.

FIG. 10 schematically illustrates software aspects of the POS terminalof FIG. 4.

FIGS. 11A and 11B together form a flow chart that illustrates atransaction process that may be performed in the system of FIG. 2 inaccordance with aspects of the present invention.

FIG. 12 schematically illustrates a clearing process that may beperformed in the system of FIG. 2 in accordance with aspects of thepresent invention.

FIG. 13 is a block diagram that illustrates an alternative embodiment ofthe payment system of FIG. 2.

FIG. 14 is a high level flow chart that illustrates a transactionprocess that may be performed in the system of FIG. 13 in accordancewith aspects of the present invention.

FIG. 15 schematically illustrates some details of the process of FIG.14.

FIG. 16 schematically illustrates a biometric-based cardholderverification method (CVM) that may be performed according to aspects ofthe invention in the system of FIG. 2 or FIG. 13.

FIG. 17 is a block diagram that illustrates aspects of thebiometric-based CVM of FIG. 16.

FIG. 18 is a block diagram that illustrates an alternative CVM that maybe performed according to aspects of the invention.

DETAILED DESCRIPTION

In general, and for the purpose of introducing concepts of embodimentsof the present invention, a payment network transaction is consummatedat the point of sale without the POS terminal receiving or reading apayment card account number. The consumer offers a payment-enabledmobile device as a credential for the transaction. The payment cardaccount number need not be stored in the mobile device, but rather hasbeen enrolled in a digital wallet maintained for the consumer by awallet service provider (WSP) that is located remotely from the point ofsale.

The POS terminal and the payment-enabled mobile device exchange data toinitiate the payment transaction. The data provided from thepayment-enabled mobile device to the POS terminal may include only (a)data to identify the consumer's WSP, and (b) an internet address for aserver function that is hosted by the payment-enabled mobile device. Thedata provided from the POS terminal to the payment-enabled mobile devicemay relate to the current purchase transaction (e.g., transactionamount) and to the transaction context (e.g., data to identify themerchant that operates the POS terminal and the location of the purchasetransaction).

The exchange of data between the POS terminal and the payment-enabledmobile device may be by any convenient mode, such as NFC.

Using the identity of the WSP as received from the payment-enabledmobile device, the POS terminal may route a message to the WSP, wherethe message contains the transaction data, the transaction context dataand the internet address for the mobile device server function. The WSPmay then use the internet address to set up a cryptographically securedcommunication channel with the mobile device via the server functionhosted by the mobile device. This may involve mutual authentication ofthe WSP's computer and the mobile device server function.

The WSP's computer may transmit wallet form data to the mobile devicevia the secure channel to permit the consumer to select a payment cardaccount from among those for which data is stored in the digital walletmaintained for the consumer by the WSP. The mobile device serverfunction may send data to the WSP's computer to serve as anauthentication token for the transaction, including data that indicatesthe consumer's selection of a payment card account to be used for thetransaction, and data by which the WSP can confirm the validity of thetransaction data and transaction context data provided to the WSP fromthe POS terminal.

The WSP may then act much like an acquirer in a conventional paymentcard system, by routing an authorization request for the transaction viathe payment network to the issuer of the selected payment card account.Upon receiving a favorable authorization response, the WSP may route aconfirmation to the POS terminal to indicate that a valid payment forthe purchase transaction has been secured. The purchase transaction isthen complete at the point of sale.

By way of background, and to more sharply illustrate differences betweenconventional practices and the teachings of the present disclosure, aconventional payment system will first be briefly described. FIG. 1 is ablock diagram that illustrates a conventional payment system 100.

The system 100 includes a conventional payment card/device 102 (whichmay alternatively be a conventional payment-enabled mobile device thatstores a payment card account number and runs a payment applet; otherform factors for the payment device, such as a fob, are also possible).The system 100 further includes a reader component 104 associated with aPOS terminal 106. In some known manner (depending on the type of thepayment card/device 102) the reader component 104 is capable of readingthe payment card account number and other information from the paymentcard/device 102.

The reader component 104 and the POS terminal 106 may be located at thepremises of a retail store and operated by a sales associate of theretailer for the purpose of processing retail transactions. The paymentcard/device 102 is shown in FIG. 1 to be interacting with the proximityreader component 104 and the POS terminal 106 for the purpose ofexecuting such a transaction.

A computer 108 operated by an acquirer (acquiring financial institution)is also shown as part of the system 100 in FIG. 1. The acquirer computer108 may operate in a conventional manner to receive an authorizationrequest for the transaction from the POS terminal 106. The acquirercomputer 108 may route the authorization request via a payment network110 to the server computer 112 operated by the issuer of a payment cardaccount that is associated with the payment card/device 102. As is alsowell known, the authorization response generated by the payment cardissuer server computer 112 may be routed back to the POS terminal 106via the payment network 110 and the acquirer computer 108.

One well known example of a payment network is referred to as the“Banknet” system, and is operated by MasterCard InternationalIncorporated, which is the assignee hereof.

The payment card issuer server computer 112 may be operated by or onbehalf of a financial institution (“FI”) that issues payment cardaccounts to individual users. For example, the payment card issuerserver computer 112 may perform such functions as (a) receiving andresponding to requests for authorization of payment card accounttransactions to be charged to payment card accounts issued by the FI;and (b) tracking and storing transactions and maintaining accountrecords.

The components of the system 100 as depicted in FIG. 1 are only thosethat are needed for processing a single transaction. A typical paymentsystem may process many purchase transactions (including simultaneoustransactions) and may include a considerable number of payment cardissuers and their computers, a considerable number of acquirers andtheir computers, and numerous merchants and their POS terminals andassociated proximity reader components. The system may also include avery large number of payment card account holders, who carry paymentcards or other devices for initiating payment transactions by presentingan associated payment card account number to the reader component of aPOS terminal

FIG. 2 is a block diagram that illustrates a payment system 200 providedin accordance with aspects of the present invention. (As was the case inFIG. 1, the payment system is depicted in FIG. 2 only in terms ofcomponents needed for a single transaction; in practice, and as will bediscussed below, the payment system 200 may include many more instancesof at least some components.)

As illustrated in FIG. 2, the payment system 200 includes apayment-enabled mobile device 202 provided in accordance with aspects ofthe present invention. The payment-enabled mobile device 202 may takethe form of a conventional-appearing smartphone, tablet computer, or thelike. However, as will be seen from subsequent discussion, the softwareconfiguration of the payment-enabled mobile device 202 may be verydifferent from previously proposed payment-enabled devices. In at leastsome embodiments, the payment-enabled mobile device 202 may not storeany payment card account information, and may lack the payment appletsthat have heretofore typically been proposed to incorporate contactlesspayment capabilities into a mobile phone. Further details of thepayment-enabled mobile device 202 will be described below, particularlyin the ensuing sections of this description relating to FIGS. 3, 7, 8and 9, and in portions of FIGS. 11A and 11B.

Also included in the payment system 200 is a merchantpoint-of-interaction (POI) terminal 204, which may be a POS terminal asconfigured in accordance with aspects of the present invention. Themerchant POI terminal 204 may, for example, be operated by a merchant(or merchant employee) at a retail store, and may interact with thepayment-enabled mobile device 202 in a manner described below (e.g., bya short-range mode of data communication). Further details of themerchant POI terminal 204 will be described subsequently, including inthe sections of the description relating to FIGS. 4 and 10.

Another feature of the payment system 200 is a computer 206 operated bya payment system acquirer (or a payment services provider—“PSP”) onbehalf of an acquirer. As is customary, the acquirer may be a financialinstitution with which the merchant maintains a banking relationship.However, as will be seen from subsequent discussion, the roles of thePSP/acquirer computer 206 in the payment system may be quite differentfrom the roles typically performed by the acquirer in a conventionalpayment system such as that illustrated in FIG. 1. A portion of theensuing discussion will describe actions taken by the PSP/acquirer, andthe computer 206, in connection with a typical payment transaction asperformed in the payment system 200.

A central aspect and component of the payment system 200 is a computer208 operated by or on behalf of a wallet service provider (WSP). It isassumed that the WSP in question maintains a digital wallet for anindividual user depicted at 210 as the user of the payment-enabledmobile device 202. Two main functional blocks of the WSP computer 208are shown in FIG. 2, namely a wallet services block 212 and atransaction concentrator block 214. The wallet services block 212enrolls consumers for digital wallet services, and allows consumers'payment card accounts to be represented in digital form in theconsumers' digital wallets to be maintained in the wallet services block212. The wallet services block 212 also serves as a repository and as aresource for digital wallet and payment card account information to beused—as will be seen—in payment transactions that are performed inaccordance with aspects of the present invention.

The transaction concentrator block 214 handles individual paymenttransactions in accordance with aspects of the present invention and asdescribed in detail below.

Also shown in FIG. 2, and forming part of the payment system 200, arethe payment network 110 and the issuer server computer 112 which werementioned in the above description of FIG. 1. Operation of the paymentsystem 200 does not necessarily require that the payment network 110 andthe issuer server computer 112 be operated in other than a conventionalmanner, and thus the payment network 110 and the issuer server computer112 may be constituted in a known manner; it should be noted though thatin effect, and as will be seen, the WSP computer 208 may serve (amongother roles) in the place of the acquirer computer 108 that was depictedin FIG. 1. Thus, and as described below, the payment network 110 mayreceive authorization requests from the WSP computer 208 as if (from thepoint of view of the payment network 110) the WSP computer 208 were anacquirer computer.

FIG. 2 also shows communication channels 216, 218, 220 and 222interconnecting certain of the components of the payment system 200.Further information about these communication channels will be providedbelow. It should also be noted that communication channel 224 (betweenthe WSP computer 208 and the payment network 110) and communicationchannel 226 (between the payment network 110 and the issuer servercomputer 112) may be provided in a conventional manner.

A detailed description of operation of the payment system 200 will beprovided below, particularly with reference to FIGS. 11A and 11B.

As noted above, the block diagram representation of the payment system200 as shown in FIG. 2 represents only system components required for asingle transaction. In a practical embodiment of the payment system 200,there may be, for example, more than one payment network thatparticipates in the system. Also, there may be a number of WSPs thatparticipate rather than just one.

Moreover, as will be understood from the above description of aconventional payment system, the payment system 200 may process manytransactions, including simultaneous transactions. A considerable numberof payment card account issuers may be included in the payment system200, and the payment system 200 may also include a considerable numberof acquirers/PSPs and their computers. In addition, the payment system200 may include a large number of merchant POI devices (in-store and/ore-commerce host computers), operated by a large number of merchants.Also, there may be a very large number of payment-enabled mobile devicesas described herein (each including the above-mentioned server functionwhich has a unique URI), and owned/used by numerous individual users.The users are holders of payment card accounts issued by issuingfinancial institutions and have enrolled with one or more WSPs, whichmaintain digital wallets for the users.

FIG. 3 is a block diagram that illustrates an example embodiment of thepayment-enabled mobile device 202 shown in FIG. 2 and provided inaccordance with aspects of the present invention. The payment-enabledmobile device 202 may be conventional in its hardware aspects. Forexample, the payment-enabled mobile device 202 may be a smartphone, andmay resemble, in some or all of its hardware aspects and many of itsfunctions, a conventional “iPhone” marketed by Apple Inc., or one of thenumerous smartphone models that run the “Android” operating system.Alternatively, the payment-enabled mobile device 202 may be a tabletcomputer, such as the “iPad” marketed by Apple Inc. The ensuingdescription of the payment-enabled mobile device 202 is based on theassumption that it is embodied as a smartphone; those who are skilled inthe art will readily understand from the following description, and fromfollowing descriptions of software aspects of the payment-enabled mobiledevice 202, how to embody the payment-enabled mobile device 202 as atablet computer or other device apart from a smartphone.

The payment-enabled mobile device 202 may include a conventional housing(indicated by dashed line 302 in FIG. 3) that contains and/or supportsthe other components of the payment-enabled mobile device 202. Thehousing 302 may be shaped and sized to be held in a user's hand, and mayfor example exhibit the type of form factor that is common with thecurrent generation of smartphones.

The payment-enabled mobile device 202 further includes conventionalcontrol circuitry 304, for controlling over-all operation of thepayment-enabled mobile device 202. For example, the control circuitry304 may include a conventional processor of the type designed to be the“brains” of a smartphone.

Other components of the payment-enabled mobile device 202, which are incommunication with and/or controlled by the control circuitry 304,include: (a) one or more memory devices 306 (e.g., program and workingmemory, etc.); (b) a conventional SIM (subscriber identification module)card 308; (c) a conventional touchscreen 312 which serves as the primaryinput/output device for the payment-enabled mobile device 202, and whichthus receives input information from the user and displays outputinformation to the user. As is the case with many models of smartphones,in some embodiments the payment-enabled mobile device 202 may alsoinclude a few physically-actuatable switches/controls (not shown), suchas an on/off/reset switch, a menu button, a “back” button, a volumecontrol switch, etc. It may also be the case that the payment-enabledmobile device 202 includes a conventional digital camera (as is the casewith many smartphones), which is not shown.

The payment-enabled mobile device 202 also includes conventionalreceive/transmit circuitry 316 that is also in communication with and/orcontrolled by the control circuitry 304. The receive/transmit circuitry316 is coupled to an antenna 318 and provides the communicationchannel(s) by which the payment-enabled mobile device 202 communicatesvia the mobile telephone communication network (not shown). Thereceive/transmit circuitry 316 may operate both to receive and transmitvoice signals, in addition to performing data communication functions.As is known to those who are skilled in the art, such data communicationmay be via HTTP (HyperText Transfer Protocol) or other communicationprotocol suitable for carrying out data communication over the internet.

The payment-enabled mobile device 202 further includes a conventionalmicrophone 320, coupled to the receive/transmit circuitry 316. Ofcourse, the microphone 320 is for receiving voice input from the user.In addition, a loudspeaker 322 is included to provide sound output tothe user, and is coupled to the receive/transmit circuitry 316.

The receive/transmit circuitry 316 may operate in a conventional fashionto transmit, via the antenna 318, voice signals generated by themicrophone 320, and to reproduce, via the loudspeaker 322, voice signalsreceived via the antenna 318. The receive/transmit circuitry 316 mayalso handle transmission and reception of text messages and other datacommunications via the antenna 318.

The payment-enabled mobile device 202 may also include circuitry 324that is partly or wholly dedicated to implementing NFC communicationsfunctionality of the payment-enabled mobile device 202. Thepayment-enabled mobile device 202 may further include a loop antenna326, coupled to the NFC circuitry 324. In some embodiments, the NFCcircuitry 324 may partially overlap with the control circuitry 304 forthe payment-enabled mobile device 202. Moreover, the NFC circuitry 324is associated with, and may also overlap with, a secure element 328 thatis part of the payment-enabled mobile device 202 and is contained withinthe housing 302, or the NFC circuitry could be omitted in embodimentsthat do not utilize NFC. The term “secure element” is well known tothose who are skilled in the art, and typically refers to a device thatmay include a small processor and volatile and nonvolatile memory (notseparately shown) that are secured from tampering and/or reprogrammingby suitable measures. In some embodiments, the secure element 328 may beprovided as part of the SIM card 308. In other embodiments, the secureelement 328 may be constituted by an integrated circuit card separatefrom the SIM card 308 but possibly having the same form factor as theSIM card 308. In some embodiments of the payment-enabled mobile device202, the secure element 328 may be conventional in its hardware aspectsbut may be programmed in accordance with aspects of the presentinvention in a manner to be described below. (It should be noted thatthe term “secure element” is not intended to be limited to devices thatare IC-based, but rather may also include any secure executionenvironment in a mobile device, and may include software based secureexecution environments running on the main mobile device processor.)

It should also be understood that the payment-enabled mobile device 202may be operable as a conventional mobile telephone forcommunication—both voice and data—over a conventional mobiletelecommunications network, which is not depicted in the drawing. Thus,the payment-enabled mobile device 202 may be in communication from timeto time in a conventional manner with a mobile network operator(“MNO”—also not shown). For example, an over-the air communicationchannel (of which an example is communication channel 222 in FIG. 2, asdiscussed further below) may be established between the payment-enabledmobile device 202 and a remote computer (e.g., the WSP computer 208).

Later sections of this disclosure, including those related to FIGS. 7-9,will discuss software aspects of the payment-enabled mobile device 202,as provided in accordance with aspects of the present invention.

FIG. 4 is a block diagram that illustrates the merchant POI terminal 204shown in FIG. 2 and provided in accordance with aspects of the presentinvention; as noted above, the merchant POI terminal 204 may be embodiedas a POS terminal at a retail store.

In some embodiments, the merchant POI terminal 204 may be largely orentirely conventional in its hardware aspects (with the possibleexception of cost reductions that may be facilitated by teachings ofthis disclosure, as described below). Nevertheless, the merchant POIterminal 204 may be programmed in accordance with aspects of the presentdisclosure to provide functionality as described herein. In addition tothe below description of functional process steps performed by themerchant POI terminal 204 as part of a typical purchase transaction(e.g., in connection with FIGS. 11A and 11B—see below), there will alsobe discussion below of some software aspects of the merchant POIterminal 204 in connection with FIG. 10. For now, however, a briefdescription of hardware aspects of the merchant POI terminal 204 willfollow, with continued reference to FIG. 4.

The merchant POI terminal 204 may include a processing element (orelements) such as the processor 402 shown in FIG. 4. The processor 402may, for example, be a conventional microprocessor, and may operate tocontrol the overall functioning of the merchant POI terminal 204.

The merchant POI terminal 204 may also include conventional peripheralcomponents, in communication with and/or controlled by the processor402, such as: (a) a keypad 404 for receiving input from the humanoperator of the POS terminal; (b) a product reader 406 for reading anyform of unique product identifier, such as a barcode or RFID, thatappears on, or is attached to, products brought to the terminal forpurchase; (c) a cash drawer 408 for storing cash received fromcustomers; (d) one or more displays 410 for providing output (e.g.,identifying products presented for purchase and their prices, indicatingsales tax due, indicating transaction subtotals and totals, etc.,providing prompts to the customer and/or to the sales associate); (e) aprinter 412 for printing out sales receipts; and (f) a communicationcontroller 414 for allowing the processor 402, and hence, the merchantPOI terminal 204 to engage in communication over data networks withother devices (e.g., the PSP/acquirer computer 206, FIG. 2). (In someembodiments, at least one of the displays 410 may be a touch screen, soas to provide an input function as well as an output function.)

In addition, the merchant POI terminal 204 may include one or morememory and/or data storage devices (indicated collectively at 416),which may comprise any combination of one or more of a hard disk drive,RAM (random access memory), ROM (read only memory), flash memory, etc.The memory/data storage device(s) 416 may store software and/or firmwarethat programs the processor 402 and the merchant POI terminal 204 toperform functionality as described herein. Thus the memory/data storagedevice(s) 416 may be in communication with the processor 402. Further,the merchant POI terminal 204 may include one or more housings (notshown) which contain and/or support one or more of the other componentsshown in FIG. 4.

In some embodiments, the merchant POI terminal 204 may depart from thecustomary hardware configuration of POS terminals, in that it may lackthe usual card-reader elements such as a mag stripe reader, a contact ICcard reader, a contactless IC card reader, etc. Instead, the merchantPOI terminal 204 may include a suitable hardware arrangement to allowfor local communications with the payment-enabled mobile device 202, tothereby establish the communication channel indicated at 216 in FIG. 2.

Referring again to FIG. 4, it is assumed for this example embodiment ofthe payment-enabled mobile device 202 that it is configured tocommunicate via NFC with the payment-enabled mobile device 202 andaccordingly the merchant POI terminal 204 includes an NFC module(reference numeral 418) for that purpose. The NFC module 418 is incommunication with the processor 402.

With the absence of card-reading capability, and also with no need toprovide security measures to safeguard PANs (primary account numbers)and other sensitive consumer information (because, as will be seen, suchinformation is never received in the merchant POI terminal 204 accordingto the processes contemplated herein), it may be possible to greatlysimplify the merchant POI terminal 204 and to reduce it in cost incomparison to widely used models of POS terminals. Nevertheless,alternative embodiments of the merchant POI terminal 204 are alsocontemplated in which, to accommodate legacy technology, card-reader(s),etc., are included so that the merchant POI terminal 204 may readconventional payment cards in addition to accepting payment via thepayment-enabled mobile device 202 as described herein.

FIG. 5 is a block diagram that illustrates an example embodiment of theWSP computer 208 as shown in FIG. 2 and provided in accordance withaspects of the present invention.

Referring now to FIG. 5, the WSP computer 208 may be conventional in itshardware aspects but may be controlled by software to cause it tofunction as described herein. For example, the WSP computer 208 may beconstituted by conventional server computer hardware. It should be notedhowever that (as discussed below) the WSP computer 208 may function as aclient device in its interactions with a server function present on thepayment-enabled mobile device 202.

The WSP computer 208 may include a computer processor 500 operativelycoupled to a communication device 501, a storage device 504, an inputdevice 506 and an output device 508.

The computer processor 500 may be constituted by one or moreconventional processors. Processor 500 operates to executeprocessor-executable steps, contained in program instructions describedbelow, so as to control the WSP computer 208 to provide desiredfunctionality.

Communication device 501 may be used to facilitate communication with,for example, other devices (such as one or more computers operated bythe payment network 110, the PSP/acquirer computer 206 and/or computersoperated by other acquirers/PSPs, and numerous payment-enabled mobiledevices such as the device 202 depicted in FIGS. 2 and 3). For example(and continuing to refer to FIG. 5), communication device 501 maycomprise numerous communication ports (not separately shown), to allowthe WSP computer 208 to communicate simultaneously with a number ofother computers and other devices, including communications as requiredto simultaneously handle numerous payment transactions.

Input device 506 may comprise one or more of any type of peripheraldevice typically used to input data into a computer. For example, theinput device 506 may include a keyboard and a mouse. Output device 508may comprise, for example, a display and/or a printer.

Storage device 504 may comprise any appropriate information storagedevice, including combinations of magnetic storage devices (e.g., harddisk drives), optical storage devices such as CDs and/or DVDs, and/orsemiconductor memory devices such as Random Access Memory (RAM) devicesand Read Only Memory (ROM) devices, as well as so-called flash memory.Any one or more of such information storage devices may be considered tobe a computer-readable storage medium or a computer usable medium or amemory.

Storage device 504 stores one or more programs for controlling processor500. The programs comprise program instructions (which may be referredto as computer readable program code means) that containprocessor-executable process steps of the WSP computer 208, executed bythe processor 500 to cause the WSP computer 208 to function as describedherein.

The programs may include one or more conventional operating systems (notshown) that control the processor 500 so as to manage and coordinateactivities and sharing of resources in the WSP computer 208, and toserve as a host for application programs (described below) that run onthe WSP computer 208.

The programs stored in the storage device 504 may also include atransaction handling application program 510 that controls the processor500 to enable the WSP computer 208 to handle requests for paymenttransactions in a manner described below in connection with FIGS. 11Aand 11B.

The storage device 504 may also store numerous instances of clientsoftware programs 512 that control the processor 500 to enable the WSPcomputer 208 to play a client role with respect to server functionshosted in numerous payment-enabled mobile devices (as provided inaccordance with aspects of the present invention) with which the WSPcomputer 208 may communicate at a given time.

In addition, the storage device 504 may store a wallet interface program514 by which the processor 500 may access digital wallet data stored inthe WSP computer 208 with respect to numerous users of the paymentsystem 200.

Still further, the storage device 504 may store an acquirer interfaceprogram 516, which provides a data communications interface to thePSP/acquirer computer 206 (FIG. 2) and to other acquirer computers thatpresent requests for transactions to the WSP computer 208.

Continuing to refer to FIG. 5, the storage device 504 may also store apayment network interface program 518, which provides a datacommunications interface to the payment network 110 (FIG. 2)—andpossibly to other payment networks as well—to allow for submission ofauthorization requests by the WSP computer 208 and receipt ofauthorization responses.

Again continuing to refer to FIG. 5, the storage device 504 mayadditionally store a CVM (cardholder verification method) processingprogram 520, which operates to handle required CVM processing withrespect to consumers who access the payment system 200 via their mobiledevices (as will be described further below).

Moreover, the storage device 504 may store a transaction clearingprogram 522, which may handle clearing of payment transactions handledvia the WSP computer 208.

The storage device 504 may also store, and the WSP computer 208 may alsoexecute, other programs, which are not shown. For example, such programsmay include a reporting application, which may respond to requests fromsystem administrators for reports on the activities performed by the WSPcomputer 208. The other programs may also include, e.g., one or moredata communication programs, device drivers, etc.

The storage device 504 may also store one or more databases 524 requiredfor operation of the WSP computer 208. Such databases may include, forexample, a database (not separately indicated in FIG. 5) for storingdata corresponding to digital wallets maintained forconsumers/cardholders in the WSP computer 208.

Like the WSP computer 208, the PSP/acquirer computer 206 may beconstituted by conventional computer hardware; thus the PSP/acquirercomputer 206 may have the same hardware architecture and aspects asdescribed above in connection with the description of the WSP computer.The computer hardware making up the PSP/acquirer computer 206 may beprogrammed to cause the PSP/acquirer computer 206 to perform functionssuch as are described below.

FIG. 6 schematically represents enrollment of a payment card accountwith a wallet service provider (e.g., the operator of WSP 208) thatparticipates in the payment system 200 of FIG. 2. In FIG. 6, the blockthat represents the WSP is labeled with reference numeral 208 which itshares with WSP computer 208 of FIGS. 2 and 5. Each WSP in the system(only one WSP is depicted but there may be a considerable number thatparticipate in the system) has a particular identifier to distinguishthe WSP from other WSPs in the system. For example, the WSP serviceprovided by the assignee hereof (MasterCard International Incorporated)is identified as “MasterPass”. A similar service available from VisaInc. is identified as “V.me”. It is assumed that the wallet servicesprovided by WSP 208 are “financial” in the sense that the accountsstored in the consumers' digital wallets maintained by WSP 208 arefinancial accounts. Other types of wallet services may also be provided,such as “value added services” (VAS) wallets, as will be described below(for instance, in connection with FIG. 13).

A user/consumer 210 is depicted in FIG. 6; this individual—it isassumed—wishes to have one of his/her payment card accounts added tohis/her digital wallet 602 maintained for him/her by the WSP 208. Itshould be understood that each consumer's digital wallet may exist as aunique entry for the consumer in a database maintained by the WSP/WSPcomputer 208. The consumer's entry/digital wallet may be identified witha unique identifier for the entry. In some embodiments of the invention,the unique identifier for the consumer's digital wallet may be aUniversal Resource Identifier (URI) that has been assigned to a serverfunction hosted on the consumer's mobile device 202 (FIG. 2). (As isknown to those who are skilled in the art, a URI uniquely identifies apoint of content in internet space, and thus may serve as an internetaddress.) It should also be noted that each consumer may be registeredwith—and hence have a respective digital wallet with—more than one WSP.In each case, for WSPs that participate in the payment system 200, theconsumer's respective digital wallet may be identified by the sameidentifier across all the WSPs, namely by the just-mentioned URI for theserver function hosted on the consumer mobile device 202.

Each consumer's digital wallet/WSP entry 602 may itself be a datarepository for storing digitalized payment cards that the consumer hasselected for inclusion in his/her digital wallet. The digitalized cardsmay be issued by the same issuing financial institution or by severaldifferent issuers. The digitalized cards may all be branded from thesame payment network or from more than one payment network. Inclusion ofdigitalized cards from a given payment network in the WSP 208's database(i.e., in consumers' digital wallets maintained by WSP 208) can occur ifthe WSP 208 has entered into a relationship with that payment network toallow the WSP to act as a quasi-acquirer with respect to that paymentnetwork.

Block 604 in FIG. 6 represents one of the user 210's payment cardaccounts that the user has elected to have included in his her digitalwallet 602 as a digitalized card 606. The particular digitalized card606 may be assigned an easy-to-recognize identifier to distinguish it(for the user) from other digitalized cards (not shown) that are alsopresent in the user's digital wallet 602.

For each digitalized card 606 in the user's digital wallet 602, there isa digitalized image of the payment card account stored in the WSPcomputer 208. The digitalized image consists of the personalizationtemplate of the card application (i.e., a software application fordigitally implementing the payment card account). The items included inthe digitalized image depend on the requirements for wallet basedtransactions as established by the payment network for which the paymentcard account was issued.

The WSP computer 208 implements an engine that emulates the card paymentapplication for the digitalized card 606. It can be said that thedigitalized card 606 is made up of the digitalized image/personalizationtemplate for the particular payment card account plus the WSP engine forthe relevant card payment application. As will be seen, the WSP 208 usesthe digitalized payment card 606 to trigger and complete wallet paymenttransactions in place of the payment account card itself

It will be noted that every payment network is likely to require the PANand the expiration date for the digitalized card image. Some paymentnetworks may also require a Card Authentication Method (CAM). Forexample, a static CAM may be required, such as the CVC2 as establishedby MasterCard or the CVV as established by Visa. Alternatively, adynamic CAM may be required, such as is provided in an EMV transaction.(As is known to those who are skilled in the art, EMV is a standard forinter-operation of IC cards with POS terminals and/or ATMs.) For adigitalized card for which EMV is required as a CAM/CVM, the WSPcomputer 208 itself may run an EMV engine. Some payment networks mayrequire a specific CVM, such as a biometric (e.g., voice recognition inreal time and/or face motion recognition), for each transaction. Othertypes of CAM/CVM requirements are also possible and/or contemplated, andsome others will be discussed below. In some embodiments, the issuer ofthe payment card account may specify one or more CVMs instead of or inaddition to CVM(s) required by the payment network.

FIG. 7 schematically illustrates software and functional aspects of thepayment-enabled mobile device 202 shown in FIGS. 2 and 3.

The payment-enabled mobile device 202 serves as the credential of theuser 210 with respect to the payment system 200 and also is themechanism by which the user 210 is able to initiate and perform paymenttransactions and otherwise to interact with the payment system 200.

One salient feature of the payment-enabled mobile device 202 is that ithosts a server function, represented at block 702 in FIG. 7. Thisfunction will sometimes be referred to as the consumer device serverfunction. In some embodiments, the consumer device server function 702may be implemented in accordance with the Smart Card Web Server (SCWS)standard promulgated by the Open Mobile Alliance (OMA), and may run onthe SIM card 308 (FIG. 3) and/or the secure element 328. Alternatively,the consumer device server function 702 may be implemented in accordancewith the GlobalPlatform Networked Framework. The latter may beadvantageous in that it supports unlimited quantities of data percommunication and thus removes the need to segment data, as may berequired in an SCWS implementation.

The WSP 208 may fulfill the role of parameterizing the consumer deviceserver function 702. The parameters to be provided may include the WSP'sidentifier in the payment system 200, and appropriate cryptographicmaterial, to allow the WSP 208 to form a secure data communicationconnection with the consumer device server function 702 during executionof a payment transaction.

Execution of a payment transaction may require services of a number ofresources within the payment-enabled mobile device 202, such as a filesystem 704.

The file system may, for example, store files related to coupons,promotional vouchers, customer loyalty points, etc.

Other necessary or desirable resources may fall into the category ofapplications (block 706), and may include a wallet selection application708, and an EMV payment application 710, among others. The walletselection application 708, as will be seen, may function to allow theuser 210 to select among payment card accounts (digitalized paymentcards) housed in the user's digital wallet. The EMV payment application710 may provide such functionality as producing a payment token for usein offline-only EMV POI terminals (for such transactions, the WSP wouldnot be involved, and the authentication token provided—as describedbelow—in consumer-device-server-function-to-WSP transactions would notbe produced).

A database (block 712, FIG. 7) may also be supported in thepayment-enabled mobile device 202 in association with one or more of theapplications 706.

The consumer device server function 702 is uniquely identified in thepayment system 200 through a unique URI, as referred to above. The URIis the root of a namespace tree, such as that depicted in FIG. 8.

As seen in FIG. 8, the above-mentioned namespace root is represented byblock 802. The wallet selection application referred to above isrepresented by block 804, and is reached through the tree via theapplications namespace (block 806) and the wallet path element (block808). Similarly, the above-mentioned EMV payment application isrepresented by block 810 in FIG. 8 and is reached through the tree viathe applications namespace 806 and the EMV path element 812.

The tree illustrated in FIG. 8 also may include a files namespace (block814). In one example embodiment, a default address leaf (block 816) isreachable via the files namespace 814 and a shipping address pathelement 818. The default shipping address may be modified by the user,and may be used to update the user's digital wallet at the WSP computer208, with the wallet selection application sending the updated addressto the WSP computer 208 in response to a call to the wallet selectionapplication.

An HTTP web client (such as a client application hosted on the WSPcomputer 208) may interact with the consumer device server function 702in the following manner, for example. The web client may ask theconsumer device server function 702 for a service through an appropriateHTTP command. The command may encode several imbricated sub-commandsthat are targeted to resources accessible via the namespace tree. Theconsumer device server function 702 may dispatch the HTTP command basedon the semantic of the command. The consumer device server function 702may identify all imbricated sub-commands to be further directed to theappropriate resources, and then sequentially sends the identifiedsub-commands to each relevant resource.

While processing a sub-command, a resource may require an interactionwith the user 210. For example, the resource (e.g., the wallet selectionapplication) may need to receive input from the user 210 concerning theuser's selection of a preferred card or set of cards to be used in acurrent payment transaction. As another example, the resource mayrequire the user to perform a CVM (e.g., PIN entry or biometric) inorder to produce proof that the user is not an impostor.

Each resource may elaborate its partial processing result correspondingto the set of sub-commands it executed and may return the partialprocessing result to the consumer device server function 702. Theconsumer device server function 702 may use the partial processingresults received from the various resources to compose the HTTP responseto be sent to the web client that made the HTTP command.

FIG. 9 illustrates still further details of software aspects of thepayment-enabled mobile device 202 shown in FIGS. 2 and 3. In particular,FIG. 9 illustrates a basic software configuration that may be providedto implement an authentication token procedure in accordance withaspects of the present invention. (In addition to the software featuresillustrated in FIG. 9, the payment-enabled mobile device 202 may befurther configured with additional software features to accommodateother functionality including possibly additional functionalitydescribed hereinbelow.)

The main software features shown in FIG. 9 are an interceptionapplication software program 902, a wallet selection application program904, and a contact exchange application software program 906. The walletselection application program 904 may coincide or overlap with thewallet selection application 708 referred to above in connection withFIG. 7. The interception application software program 902, the walletselection application program 904 and the contact exchange applicationsoftware program 906, may in some embodiments run on the secure element328 (FIG. 3, also depicted in FIG. 9). There are other possiblearrangements for providing an operating environment within thepayment-enabled mobile device 202 for these software features, as willbe understood from the above discussion of FIG. 3.

The interception application software program 902 may serve as a frontend of the consumer device server function 702 referred to in connectionwith FIG. 7 and may provide the connection for the server function withthe outside world, while dispatching sub-commands to internal softwareresources of the payment-enabled mobile device 202. For example, theinterception application software program 902 may perform some or all ofthe following tasks, among others: (a) Establishing an HTTPcommunication session with an HTTP client (such as a client programrunning on the WSP computer 208, FIG. 5); and (b) determining what typeof client is requesting service and applying appropriate accesscondition mechanisms to guarantee that each client is only permitted toask for services to which it is entitled (the clients in question mayinclude the WSP client—as just mentioned, a client program running onthe payment-enabled mobile device 202, or another web client).

Moreover, if the HTTP client is the WSP computer 208, the interceptionapplication software program 902 may establish a secure communicationtunnel with the WSP computer 208 by taken such actions as: (a)successful authentication of the WSP computer 208; (b) providingauthenticable information to the WSP computer 208 to certify that thepayment-enabled mobile device 202 and the consumer device serverfunction 702 are eligible for participation in the payment system 200and were issued/enrolled by the operator of the WSP computer 208 (i.e.,by the wallet service provider in question); and (c) establish securecommunications with the WSP computer 208. The resulting communicationsession will provide encryption, data integrity and data originauthentication of all the data transferred between the payment-enabledmobile device 202 and the WSP computer 208. Various secure tunnelingtechnologies can be used for this purpose, in accordance with thecommunication security aspects implemented in the payment-enabled mobiledevice 202 and the WSP computer 208.

Once a secure communication channel has been established between the WSPcomputer 208 and the consumer device server function 702, the clientrunning in the WSP computer 208 can submit any type of HTTP request tothe consumer device server function 702, with imbricated sub-commands toapplication resources within the payment-enabled mobile device 202.

Establishment of the secure communication channel between the WSPcomputer 208 and the consumer device server function 702 may involve useof a set of cryptographic keys previously loaded into thepayment-enabled mobile device 202 during a personalization processperformed by the WSP computer 208 with respect to the interceptionapplication software program 902.

In a case where the client making the request is one that runs on thepayment-enabled mobile device 202 itself, the interception applicationsoftware program 902 may filter the sub-commands submitted by the clientto limit the client's request to actions such as selecting one or morepayment card accounts and corresponding amounts to be charged to theaccounts in accordance with options presented in a wallet selection formuploaded from the WSP client to the consumer device server function 702for purposes of a current transaction. In this case the WSP computer 208may consider the HTTP response from the consumer device server function702 (i.e., conveying the wallet selection data as indicated by the user)if and only if such information is coming to the WSP computer 208 viathe secure communication channel referred to above and establishedbetween the WSP client and the interception application software program902. In this case, the communication of the wallet selectioninformation, in a suitably secure manner, may be deemed anauthentication token submitted for the transaction by thepayment-enabled mobile device 202. It will be appreciated that theuser's selection of wallet options as communicated via theauthentication token may involve interaction between the user and thewallet selection application program 904.

Another action that the interception application software program 902may permit a client on the payment-enabled mobile device 202 to performmay be a CVM for authentication of the user as the legitimate owner ofthe payment-enabled mobile device 202.

Still another action that the interception application software program902 may permit a client on the payment-enabled mobile device 202 toperform may be selection of a communication technology (e.g., NFC,Bluetooth, Wi-Fi, QR code, SMS, USSD, etc.) as the mode of communicationavailable between the payment-enabled mobile device 202 and the merchantPOI terminal 204 (FIG. 2) for exchanging contact and transaction databetween the payment-enabled mobile device 202 and the merchant POIterminal 204.

In some embodiments, the interception application software program 902may function such that other clients (e.g., a client program running onthe merchant POI terminal 204) may only send information to anapplication resource on the payment-enabled enabled mobile device 202.For example, the interception application software program 902 maypermit a client running on the merchant POI terminal 204 to sendtransaction detail data to the contact exchange application softwareprogram 906, without requesting processing, and the contact exchangeapplication software program 906/interception application softwareprogram 902 may return contact information for the payment-enabledmobile device 202, such as data that identifies the WSP for the user ofthe payment-enabled mobile device 202, and the URI for the consumerdevice server function 702 on the payment-enabled mobile device 202.

Turning now to the wallet selection application program 904, the lattermay serve as a resource application that receives data communicated fromthe WSP computer 208 via the secure tunnel established between theinterception application software program 902 and the WSP computer 208.This data may include data retrieved by the WSP computer 208 from thedigital wallet it maintains for the user of the payment-enabled mobiledevice 202. This data may be referred to as “wallet form data”, and maybe such as is needed to allow the user to interact with a client runningon the payment-enabled mobile device 202 to visualize his/her digitalwallet as maintained on the WSP computer 208. With this data, the useris able to choose from his/her digital wallet a payment card account (ormore than one such account) to be used for a current transaction. (I.e.,it is contemplated that the user may pay for the entire transaction withone payment card account in his/her wallet, or alternatively he/she maysplit the transaction amount for funding by two or more of the paymentcard accounts represented in his/her digital wallet.)

Depending on the requirements set forth by the payment network (and/orthe issuer) in question, the wallet selection application program 904may require the user to perform a specific CVM. For example, the CVM maycall for one or more of the following: (a) entry by the user of anoverall wallet access password (not specific to a particular paymentcard account); (b) entry by the user of the PIN for a particular paymentcard account selected by the user for the current transaction; and/or(c) submission by the user of biometric input. (As just one example ofthe latter, where the transaction is to be funded wholly or in part froma social benefits (e.g., a government pension/social security scheme)account, the required CVM may include submission of a biometric thatprovides “proof of life”—one example of such a biometric would be aspoken utterance by the user to be processed for voice recognition;subsequent discussion herein will describe some examples ofvoice-recognition-based CVMs that may be provided in accordance withaspects of the present invention.)

The discussion will now turn to the contact exchange applicationsoftware program 906. The contact exchange application software program906 may also be a resource application on the payment-enabled mobiledevice 202 and may serve to permit the user to exchange data with themerchant POI terminal 204. For example, the contact exchange applicationsoftware program 906 may supply to the merchant POI terminal 204 addressdata that identifies the (or a) WSP for the user. In some embodiments,this address data may simply be an identifier by which the WSP isrecognized or designated in the payment system 200. In addition, thecontact exchange application software program 906 may supply to themerchant POI terminal 204 address data for the payment-enabled mobiledevice 202, such as the above-mentioned URI which serves as an internetaddress for the consumer device server function 702 (which mayultimately be passed on to the WSP computer 208, via the merchant POIterminal 204 and the PSP/acquirer computer 206).

In terms of data communicated in the other direction, i.e., from themerchant POI terminal 204 to the contact exchange application softwareprogram 906, the latter data may include data concerning the presenttransaction (which may be denoted as “transaction detail data” and whichmay include the transaction amount, for example), and also may includedata concerning the context (“transaction context data”), such as datarelated to identification of the merchant, the merchant location, and/orthe particular merchant POI terminal 204 in question.

To enable the communication between the contact exchange applicationsoftware program 906 and the merchant POI terminal 204 it may benecessary for there to be agreement on a mode of peer-to-peercommunication by which the data is to be exchanged. In some embodiments,the mode of communication may be selected by the user, who may provideinput into the payment-enabled mobile device 202 to select, e.g., one ofa list of communication modes displayed on the merchant POI terminal 204as visual icons that are viewable by the user. For example, thecommunication options may include one or more of NFC, Bluetooth, WiFi,QR code and/or USSD.

As noted before, and among a number of possibilities, the consumerdevice server function 702 may be configured to operate in accordancewith GPNF, as promulgated by GlobalPlatform, and/or in accordance withthe SCWS (Smart Card Web Server) standard published by OMA. Also asnoted above, hardware options for the payment-enabled mobile device 202may include a generally conventional smartphone, e.g., with the consumerdevice server function 702 running on an IC card installed in thesmartphone.

FIG. 10 schematically illustrates software aspects of the merchant POIterminal 204 (FIGS. 2 and 4). As can be gathered from FIG. 2, themerchant POI terminal 204 may serve as the device that represents themerchant in a particular purchase transaction, and interacts on one handwith the payment-enabled mobile device 202 and on the other hand withthe PSP/acquirer computer 206.

At a higher level of the software in the merchant POI terminal 204(reference numeral 1002 in FIG. 10), a contact exchange terminalapplication 1004 is provided to interact with the payment-enabled mobiledevice 202, and a PSP/acquirer application 1006 is provided to interactwith the PSP/acquirer computer 206.

Relative to the contact exchange terminal application 1004 and theinteraction with the payment-enabled mobile device 202, the contactexchange terminal application 1004 may establish a handshake with thecontact exchange application software program 906 in the payment-enabledmobile device 202 to allow the following data exchange: (a) (frommerchant POI terminal 204 to payment-enabled mobile device 202)transmission of the transaction detail data for the current transactionand the transaction context (merchant context) data for the currenttransaction; and (b) (from payment-enabled mobile device 202 to merchantPOI terminal 204) transmission of the URI for the consumer device serverfunction 702 and the identifier for the user's WSP.

Relative to the PSP/acquirer application 1006 and the interaction withthe PSP/acquirer computer 206, the PSP/acquirer application 1006 mayestablish an internet connection with the PSP/acquirer computer 206using, for example, TLS (transport layer security) tunneling via theinternet to enable the following exchanges of data: (a) (from merchantPOI terminal 204 to PSP/acquirer computer 206) the PSP/acquirerapplication 1006 transmits the contact details for the payment-enabledmobile device 202 (i.e., WSP identifier and URI for the consumer deviceserver function 702) and the same transaction detail data andtransaction context data that the contact exchange terminal application1004 provided to the contact exchange application software program 906;and (b) (from PSP/acquirer computer 206 to merchant POI terminal 204;after interaction between the PSP/acquirer computer 206 and the WSPcomputer 208) the PSP/acquirer application 1006 running in the merchantPOI terminal 204 receives a transaction result (e.g., approve/decline),to indicate that the purchase transaction may be completed.

At a lower level of the software in the merchant POI terminal 204(reference numeral 1008 in FIG. 10) communication protocol software maybe provided, including communication protocol software elements 1010-1through 1010-n for communicating with the payment-enabled mobile device202, and an internet/GPRS (General Packet Radio Service) communicationprotocol software element 1012. Communications via the latter may insome embodiments eventually pass through a WiFi connection. Thecommunication protocol software element 1012 may provide at least partof the communication link between the merchant POI terminal 204 and thePSP/acquirer computer 206.

FIGS. 11A and 11B together form a flow chart that illustrates atransaction process that may be performed in the payment system 200(FIG. 2) in accordance with aspects of the present invention.

At block 1102 in FIG. 11A, a purchase transaction is initiated. Forexample, in the context of a brick-and-mortar retail store, a customer(user 210 of the payment-enabled mobile device 202) may selectmerchandise and present it for purchase at a point-of-sale counter. (Aswill be understood from a later section of this disclosure, the processof FIGS. 11A and 11B is also generally applicable to the environment ofan e-commerce transaction.)

At 1104 in FIG. 11A, transaction data is input into the merchant POIterminal 204, which may be located at the point-of-sale counter. Thismay occur, for example, by the merchant sales associate operating themerchant POI terminal 204 by, e.g., scanning barcodes on the merchandiseto allow input to the merchant POI terminal 204 of the identifiers ofthe merchandise items and also to allow for lookup by the merchant POIterminal 204 of price information for the merchandise items. As a resultof this operation, the merchant POI terminal 204 may calculate a totalamount for the purchase transaction (transaction amount). In addition,the merchant POI terminal 204 may generate other transaction dataincluding, for example, a data element that indicates what currency thetransaction amount is denominated in, as well as the date of thetransaction.

At 1106, the merchant POI terminal 204 may transmit the transactiondetail data (e.g., amount, currency, date, etc.) to the payment-enabledmobile device 202, and at the same time the merchant POI terminal 204may transmit transaction context data to the payment-enabled mobiledevice 202. For example, the transaction context data may include amerchant identifier and location (which may be parameters stored in themerchant POI terminal 204). In addition, the transaction context datamay include a unique transaction number (UTN). In some embodiments, themerchant POI terminal 204 may generate a fresh UTN for each transactionit handles. For example, the merchant POI terminal 204 may calculate theUTN as a hash of such information as the merchant identifier, thetransaction location, a transaction counter value, and possibly otherinformation as well. The merchant POI terminal 204 may operate toincrement the transaction counter value with each transaction thatoccurs at the merchant POI terminal 204.

At 1108, the payment-enabled mobile device 202 may transmit data to themerchant POI terminal 204 to permit the payment-enabled mobile device202 to be contacted for a subsequent stage (token passing) of thetransaction process. As mentioned before, the data transmitted from thepayment-enabled mobile device 202 to the merchant POI terminal 204 maybe address data, in particular: (a) the identifier for the WSP thatstores the digital wallet for the user (or at least one of the user'sdigital wallets), and (b) the URI for the consumer device serverfunction 702 hosted in the payment-enabled mobile device 202. (It isworth noting at this point that in some embodiments of the invention andof the payment-enabled mobile device 202, the user may be prompted toselect a WSP and/or a digital wallet from among a plurality of his/herWSPs/digital wallets before step 1108 occurs and/or the user may makesuch a selection without being prompted and perhaps while approachingthe point-of-sale counter. It is within the contemplation of aspects ofthis invention that the payment-enabled mobile device 202 may run aWSP-selection app or the like for this purpose.)

It should also be noted that the communication channel 216 (FIG. 2)between the payment-enabled mobile device 202 and the merchant POIterminal 204 need not be highly secure, as no highly sensitive data suchas a PAN (primary account number) is being exchanged between the twodevices.

At 1110 in FIG. 11A, the merchant POI terminal 204 may transmit data tothe PSP/acquirer computer 206. This may occur over communication channel218 (FIG. 2), which may be implemented over a wide-area network such asthe internet or GPRS. The communication channel 218 may be secured by anappropriate measure, such as TSL. The data transmitted at 1110 mayinclude the address data that the merchant POI terminal 204 receivedfrom the payment-enabled mobile device 202 at 1108, and transaction datasuch as the transaction details, the transaction context and the currenttransaction counter value.

Following block 1110 in FIG. 11A is decision block 1112. In someembodiments, the determination represented by decision block 1112 may bemade by and at the PSP/acquirer computer 206. For example, the merchantPOI terminal 204 may check that the merchant is duly eligible toparticipate in the payment system 200 in the manner requested by themerchant POI terminal 204. This may involve the PSP/acquirer computer206 searching for the merchant identifier (included in the transactioncontext data) in one or more merchant subscription tables. If thePSP/acquirer computer 206 determines that the merchant is eligible torequest the transaction, then the PSP/acquirer computer 206 may proceedwith further checks, such as checking that the transaction counter isfresh and that the UTN is valid relative to the merchant.

In addition, the PSP/acquirer computer 206 may check the identificationof the WSP to confirm that the WSP is validly enrolled in the paymentsystem 200. This may occur in a manner that is analogous to aconventional operation in which an acquirer may confirm the validity ofa payment network for which a PAN-based authorization request is to besubmitted.

Assuming that the checks all result in satisfactory findings, block 1114may follow decision block 1112 in the process of FIGS. 11A and 11B. Atblock 1114, the PSP/acquirer computer 206 may transmit data to the WSPcomputer 208. As part of this operation, the PSP/acquirer computer 206may use the identifier of the WSP as received from the merchant POIterminal 204 to determine that it should establish a securecommunication channel (channel 220 in FIG. 2) with the appropriate WSP.This may be done over the internet, for example, with TSL. The datatransmitted at 1114 may include all the data received by thePSP/acquirer computer 206 at 1110, except possibly excluding thetransaction counter value provided by the merchant POI terminal 204. Itwill be noted that, according to aspects of this invention, this datawill typically include the URI for the consumer device server function702 hosted on the payment-enabled mobile device 202.

Block 1116 follows block 1114. At block 1116, the WSP computer 208receives and processes the data transmitted by the PSP/acquirer computer206. In particular, the WSP computer 208 may generate a transactionidentifier, which may for example be formed from the merchant identifier(corresponding to the merchant that operates the merchant POI terminal204) plus the UTN provided in the message received by the WSP computer208 from the PSP/acquirer computer 206. Further as part of the operationof block 1116, the WSP computer 208 may store the transaction data(transaction detail data and transaction context data), as received fromthe PSP/acquirer computer 206, in association with the transactionidentifier generated by the WSP computer 208. Still further as part ofthe operation of block 1116, the WSP computer 208 may read, from thedata supplied by the PSP/acquirer computer 206, the URI for the consumerdevice server function 702 hosted in the payment-enabled mobile device202. Next, the WSP computer 208 may verify that the URI in question isnot blacklisted and that the user in question has a valid subscriptionto the wallet services provided by the WSP that operates the WSPcomputer 208.

Block 1118 follows block 1116. At block 1118, the WSP computer 208 goeson to retrieve the wallet entry for the user of the payment-enabledmobile device 202, as identified by the above-mentioned URI. With thedata from the user's wallet entry (i.e., the user's digital walletmaintained by the WSP computer 208), the WSP computer 208 forms walletform data to be sent to the consumer device server function 702 hostedin the payment-enabled mobile device 202. The wallet form data willpresent information to the user to permit him/her to choose among thepayment card accounts in his/her digital wallet to select the account(s)to be used for the current transaction. If the user wishes to use morethan one of his/her accounts and to distribute the transaction amountamong the selected accounts, the wallet form data may allow the user toindicate his/her choices in this regard as well.

Block 1120 follows block 1118. At block 1120, the WSP computer 208 usesthe URI for the consumer device server function 702 hosted in thepayment-enabled mobile device 202 to initiate formation of a securecommunication channel (channel 222 in FIG. 2) between the WSP computer208 and the consumer device server function 702 hosted in thepayment-enabled mobile device 202. For example, a so-called securetunneling technology may be employed, such as one of the publishedprotocols known as “SCP” (secure channel protocol). The consumer deviceserver function 702 hosted in the payment-enabled mobile device 202 (andparticularly, the interception application software program 902)cooperates with the WSP computer 208 in exchanging information necessaryfor the WSP computer 208 and the consumer device server function 702hosted in the payment-enabled mobile device 202 to mutually authenticateeach other. With the successful formation of the secure communicationchannel 222, it is established that the WSP computer 208 and theconsumer device server function 702 hosted in the payment-enabled mobiledevice 202 have mutually authenticated each other, and enciphering ofcommunications in both directions through the channel 222 is enabled.

Referring again to the flowchart of FIGS. 11A-11B, and particularly toFIG. 11B, block 1122 follows block 1120. At block 1122, the WSP computer208 transmits the above-referenced wallet form data to thepayment-enabled mobile device 202 (i.e., to the consumer device serverfunction 702). Then block 1124 follows block 1122. At 1124, thepayment-enabled mobile device 202 (particularly the interceptionapplication software program 902) decrypts the wallet form data andsubmits the information contained in the wallet form data to the uservia the wallet selection application program 904. Using the interfaceprovided to him/her via the payment-enabled mobile device 202, the user210 selects the account(s) for the current transaction, and if necessarythe respective amounts for funding by each account, if more than oneaccount is selected. The resulting account selection data is providedwithin the payment-enabled mobile device 202 to the interceptionapplication software program 902. (It may be the case that, inconnection with the user's interaction with the wallet selectionapplication program 904, the user may be required to properly complete aCVM process, such as those referred to above. For example, PIN entryand/or submission of biometric input may be required. In someembodiments, the resulting data ultimately is passed along to the WSPcomputer 208 for verification.)

Block 1126 follows block 1124. As part of the operation of block 1126,the interception application software program 902 generates anauthentication token for the transaction. The interception applicationsoftware program 902 may generate the authentication token as a MessageAuthentication Code (MAC) on the basis of the account selection data,and the transaction data (transaction detail data and transactioncontext data) that the payment-enabled mobile device 202 had received atblock 1106 (FIG. 11A) from the merchant POI terminal 204. Also as partof the operation of block 1126, the interception application softwareprogram 902 may generate a transaction identifier, which may contain themerchant identifier for the transaction plus the UTN generated for thetransaction by the merchant POI terminal 204 and transmitted to thepayment-enabled mobile device 202 at block 1106. The interceptionapplication software program 902 (and hence the payment-enabled mobiledevice 202) may then transmit the following data to the WSP computer208: (a) the account selection data, as indicated by the user 210 at1124; (b) the transaction identifier, and (c) the authentication token.It should be noted that although the payment-enabled mobile device 202may not transmit the transaction data (i.e., the transaction detail dataand the transaction context data) in their complete form to the WSPcomputer 208, nevertheless, because the authentication token is based onthe transaction data (with other data elements), the authenticationtoken may be considered a verifiable copy of the transaction data.

Continuing to refer to FIG. 11B, block 1128 follows block 1126. At block1128, the WSP computer 208 receives the data transmitted from thepayment-enabled mobile device 202 (i.e., from the interceptionapplication software program 902/consumer device server function 702).Using the transaction identifier provided by the payment-enabled mobiledevice 202, the WSP computer 208 matches the data received from thepayment-enabled mobile device 202 with the data it had stored for thetransaction in association with the transaction identifier as generatedby the WSP computer 208 at block 1116. The WSP computer 208 identifiesthe transaction detail data and the transaction context data that it hadpreviously stored (after receiving same from the PSP/acquirer computer206 at 1116) and proceeds to verify the authentication token as providedby the consumer device server function 702 hosted in the payment-enabledmobile device 202. In doing so, the WSP computer 208 in effect confirmsthat the transaction detail data and the transaction context data asreflected in the authentication token match the transaction detail dataand the transaction context data as received by the WSP computer 208from the PSP/acquirer computer 206. Verification of the authenticationtoken by the WSP computer 208 indicates to the WSP computer 208 that theaccount selection data from the payment-enabled mobile device 202 isvalid and has the effect of a payment order to be executed by the WSPcomputer 208.

Block 1130 follows block 1128. It will initially be assumed for thepurpose of describing block 1130 that the user 210 had selected only onepayment card account from his/her digital wallet to fund the currenttransaction. Accordingly, at 1130 the WSP computer 208, actingsubstantially like a conventional acquirer, uses the PAN for theuser-selected payment card account (as stored in and retrieved from theuser's digital wallet) to route a payment network authorization requestvia the indicated payment network (assumed to be the payment network 110shown in FIG. 2) to the issuer of the user-selected payment card account(assumed to be the issuer 112 shown in FIG. 2).

Now, for an alternate description of block 1130, it will be assumed thatthe user selected more than one payment card account from his/herdigital wallet, for distribution of the transaction amount among theselected payment card accounts. In this case, the account selection dataprovided by the payment-enabled mobile device 202 to the WSP computer208 may include two or more lines, with each line corresponding to arespective user-selected account and with each line indicating theportion of the transaction amount to be charged to the respectiveaccount. For each such account, the WSP computer 208 may issue arespective authorization request via the appropriate payment network(i.e, more than one payment network may be involved in the currenttransaction, although only one payment network is depicted in FIG. 2)for routing to the respective issuer for the account.

Continuing to refer to FIG. 11B, block 1132 follows block 1130. At block1132, the WSP computer 208 receives a substantially conventionalauthorization response message, which originated from the issuer 112 andwhich was routed to the WSP computer 208 via the payment network. Itwill next be assumed that the authorization response indicates approvalby the issuer of the authorization request initiated by the WSP computer208 (or, if more than one payment card account had been selected by theuser, it is assumed that all of the authorization responses from theissuers indicate approval), in which case, block 1134 follows block1132.

At block 1134, the WSP computer 208 transmits an acknowledgment messageto the PSP/acquirer computer 206 to confirm that payment has been dulymade for the current transaction. Block 1136 then follows. At block1136, the PSP/acquirer computer 206 transmits an acknowledgment messageto the merchant POI terminal 204 to confirm that payment has duly beenmade for the current transaction. Block 1138 then follows, at which thepurchase transaction at the retail store is completed. For example, themerchant POI terminal 204 may display to the merchant's sales associatean indication that payment has been acknowledged/confirmed, and mayprint a suitable receipt for the customer/mobile device user 210. Thecustomer may then leave the retail store with the purchased merchandiseand the receipt.

The payment system 200, as described herein, may provide enhancedsecurity for sensitive information such as payment card account PANs ascompared to conventional payment systems in which the merchant reads thePAN from a card or other device at the point of purchase. In the paymentsystem 200, the merchant never has possession of the customer's PAN;accordingly, a mass data breach at the merchant level, with attendantdifficulties and potential exposure to fraud, may be highly unlikely orimpossible with the payment system 200.

Moreover, because the PAN and related data do not pass through the POSterminal (also referred to as the POI terminal) in the payment system200, the cost of the POS terminal may be substantially reduced ascompared to conventional POS equipment currently in use. For example, inthe POI terminal as described herein, there may be no need for the typeof complex cryptographic calculations that are employed in someconventional POS equipment. Accordingly the POI terminal as describedherein may be simplified in that it may not need to have either a fastmain processor and/or a specialized cryptographic processor, such as maybe included in conventional POS equipment. Moreover, with thisarrangement PCI compliance may not be required for the POI terminalThere may also be savings with respect to the software that programs thePOI terminal as described herein in that the software itself may be lesscomplex than conventional POS equipment software, and may be subject toless complex certification processes than are conventionally employed inmany cases for POS equipment software.

Further, in other hardware respects the POI terminal described hereinmay be simplified, in that there may be no need for such components as asecure keyboard, a secure biometric sensor or a secure display device.In general, tampering detection and tampering reaction mechanisms maynot be needed in the POI terminal described herein, because the POIterminal no longer handles payment application processes, but rather isa protocol adapter for exchanging basic information between the customerand the merchant, while also relaying basic information from theconsumer device server function 702 hosted in the payment-enabled mobiledevice 202 to the PSP/acquirer and on to the WSP.

It is another advantage of the payment system 200 that, in contrast toother payment token systems that have been proposed, there arepotentially an unlimited number of authentication tokens available asthe same have been described in this disclosure.

Still further, since the payment-enabled mobile device 202 provides arepresentation of transaction data to the WSP computer 208, forcomparison by the WSP computer 208 with the transaction data receivedfrom the merchant POI terminal 204 via the PSP/acquirer computer 206,there is enhanced protection against fraudulent unsolicitedtransactions.

In the above discussion of the embodiment shown in FIG. 2 and subsequentdrawings, it has been assumed that the merchant POI terminal 204 waslocated at the point of sale in a brick-and-mortar retail store.However, in other embodiments of the payment system 200, the merchantPOI terminal 204 may for example be constituted by an e-commerce serveroperated by a merchant to handle online purchase transactions. In suchembodiments, the customer may access the merchant POI terminal 204initially in a conventional manner (e.g., via a browser running on apersonal computer), or alternatively may use a mobile device browserrunning on his/her smartphone/mobile device (which may also be theabove-described payment-enabled mobile device 202). In any case, for thepayment portion of the transaction, the merchant POI terminal 204 andthe payment-enabled mobile device 202 may exchange such information asis described above in connection with blocks 1106 and 1108. This mayoccur, for example, via such communication modes as SMS (short messageservice) or USSD (unstructured supplementary service data). The exchangeof this information may alternatively be conducted via HTTPcommunications, with the mobile device 202 acting as a client andconnecting to the merchant's website via its browser. For these purposesthe payment-enabled mobile device 202 may exchange communications withthe merchant POI terminal 204 via a mobile communications network (notshown) for which the payment-enabled mobile device 202 is a subscriberdevice. In other ways, for this case of the merchant POI terminal 204 asan e-commerce server, the process as described above in connection withFIGS. 11A/11B may be quite similar.

Referring again to the case where the purchase transaction occursface-to-face, the merchant POI terminal 204 and the payment-enabledmobile device 202 may be able to interact directly via a bidirectionalexchange. To establish the bidirectional exchange, the merchant POIterminal 204 and the payment-enabled mobile device 202, acting as peerdevices, may perform an automatic setup of a bidirectional channelbetween the two devices. This could occur in a number of ways, dependingon the features present in the devices. For example, this could be donedirectly through an NFC peer-to-peer data exchange. This may be anadvantageous approach in that it takes advantage of existing smartphonecapabilities.

However, in other embodiments, or if additional features require alarger volume of data to be exchanged, the bidirectional communicationcould occur through a process where the devices cooperate via NFC totransfer over to another technology such as Bluetooth or WiFi.

As another alternative, and as suggested above (and in either aface-to-face or remote transaction situation), the merchant POI terminal204 and the payment-enabled mobile device 202 may interact outside acommunication channel. For example, via USSD or SMS, the payment-enabledmobile device 202 may submit the information referred to in connectionwith block 1108 to a phone number visually displayed on the merchant POIterminal 204. As another possibility, the payment-enabled mobile device202 (assuming it includes a camera, as many smartphones do), may capturean image of a QR code (quick response code) as displayed by the merchantPOI terminal 204 (or downloaded from the merchant, in the case where themerchant POI terminal 204 is an e-commerce server).

In the embodiment shown in FIG. 2, the PSP/acquirer computer 206functions essentially as a switch between merchant devices and WSPs. Itis contemplated that some embodiments may omit the PSP/acquirer computer206 in favor of a direct communication link between the merchant POIterminal 204 and the WSP computer 208. However, it may be advantageousto have acquirers as a layer between merchants and WSPs to aid inmanaging the workload for the WSPs and to enhance scalability of thepayment system 200. It may also aid in fast and efficient conflictresolution and chargebacks to have acquirers present in the paymentsystem 200 between merchants and WSPs.

FIG. 12 schematically illustrates a clearing process that may beperformed in the system 200 of FIG. 2 in accordance with aspects of thepresent invention.

In FIG. 12, payment card issuers' settlement accounts are indicated at1202. The settlement accounts of payment networks are indicated at 1204.(Although only one payment network account 1204 is shown as havingpayment card issuers' accounts feeding into it, in practice, as will beappreciated, the same will be true of all of the payment networksettlement accounts.)

A first level of the clearing process is indicated at 1206, and featuresa WSP 1208, having a WSP pool account 1210. A second level of theclearing process is indicated at 1212, and features settlement accounts1214 belonging to PSPs/acquirers.

Also shown in FIG. 12 are merchant settlement accounts 1216. (Tosimplify the drawing, only one of the PSP/acquirer settlement accounts1214 is shown feeding merchant settlement accounts 1216; however it willbe understood that in practice all the PSP/acquirer settlement accounts1214 would do the same.)

One of the payment card issuer settlement accounts 1202 may beassociated with the issuer 112 shown in FIG. 2. One of the paymentnetwork settlement accounts 1204 may be associated with the paymentnetwork 110 shown in FIG. 2. The WSP 1208 shown in FIG. 12 may be theoperator of the WSP computer 208 shown in FIG. 2. One of thePSP/acquirer settlement accounts 1214 shown in FIG. 12 may be associatedwith the operator of the PSP/acquirer computer 206 shown in FIG. 2. Oneof the merchant settlement accounts 1216 shown in FIG. 12 may beassociated with the merchant that operates the merchant POI terminal 204shown in FIG. 2.

It will be understood that two or more different payment networks arerepresented in the payment network settlement accounts 1204 shown inFIG. 12, whereas those two or more different payment networks are alsoparticipants in the payment system 200 (notwithstanding that only onepayment network is explicitly shown in FIG. 2).

Block 1210 shown in FIG. 12, in addition to representing the WSP poolaccount, should also be understood to represent a computer that managesthe flow of clearing credits into and out of the pool account. Thatcomputer may be operated by a financial institution, by the WSP, or byanother entity and may for example be the WSP computer 208 of FIG. 5.

At the first level 1206 of the clearing process, the WSP 1208 has a rolelike a “mega” acquirer, and each PSP/acquirer represented in FIG. 12 hasa role like a “mega” merchant. The clearing between the WSP 1208 and thepayment card issuers occurs in the same manner as conventional clearingbetween an acquirer and issuers through a payment network. The WSP 1208manages the pool account 1210 to receive clearing credits from thepayment network settlement accounts 1204, where the clearing creditsoriginated from payment card accounts issued by the payment card issuersrepresented in FIG. 12. Moreover, the WSP 1208 manages the pool account1210 to distribute the clearing credits among the PSP/acquirersettlement accounts 1214.

At the second level 1212 of the clearing process, each acquirer managesits respective settlement account 1214 to clear credits due to itssubscriber merchants. In particular, each of the PSP/acquirer settlementaccounts 1214 receives clearing credits from the WSP pool account 1210,and those credits are further distributed to the merchant accounts 1216.

The layered clearing process as illustrated in FIG. 12 may aid inenhancing the scalability of the payment system 200. FIG. 12 alsoillustrates how funds flow among participants in the acquiring processwith appropriate service fees accruing.

FIG. 13 is a block diagram that illustrates an alternative embodiment(generally indicated by reference numeral 200 a in FIG. 13) of thepayment system of FIG. 2.

The payment system 200 a shown in FIG. 13 may include essentially all ofthe components of the payment system 200 as described in connection withFIG. 2 and subsequent drawings. In addition, the payment system mayinclude a value added services (VAS) WSP computer 1302 that is connected(at least from time to time) to an PSP/acquirer computer 206 a via acommunication channel 1304. (The PSP/acquirer computer 206 a shown inFIG. 13 may include all of the functionality of the PSP/acquirercomputer 206 shown in FIG. 2 and as described above, and in addition mayperform additional switching and/or other functions to accommodate valueadded services/split payment functionality in the payment system 200 aof FIG. 13.) The VAS WSP computer 1302 may maintain for the user 210(and many other users as well) one or more digital wallets by which theuser 210 may access and select funding from benefit accounts (i.e., notfrom payment card accounts). The benefits accessible via the user'sdigital wallet at VAS WSP computer 1302 may include one or more of thefollowing: (a) coupons, (b) loyalty/rewards points, (c) medicalinsurance benefits, (d) pension and/or social insurance and/or socialwelfare benefits, (e) casualty insurance benefits, etc.

FIG. 13 also shows two main functional blocks of the VAS WSP computer1302, namely a split amount engine 1306 and a VAS wallet servicescomponent 1308. The split amount engine 1306 may perform logic requiredto split payment in the payment system 200 a between benefit funding andpayment card account funding.

The VAS wallet services component 1308 may maintain the VAS/benefitfunds digital wallets for users of the payment system 200 a.

Also shown in FIG. 13 is a benefits system operator computer 1310. Thebenefits system operator computer 1310 may be connected to the VAS WSPcomputer 1302, at least from time to time, via a communication channel1312; in some embodiments, a one-to-one connection may be providedbetween the benefits system operator computer 1310 and the VAS WSPcomputer 1302 as part of a dedicated financial services communicationsnetwork.

The VAS WSP computer 1302, the benefits system operator computer 1310and the PSP/acquirer computer 206 may all be constituted by conventionalcomputer hardware, such as that described above in connection with thedescription of the WSP computer 208 hardware shown in FIG. 5. The VASWSP computer 1302, the benefits system operator computer 1310 and thePSP/acquirer computer 206 may be programmed to provide systemfunctionality as described herein.

The VAS WSP computer 1302 may store (in a storage medium such as thosereferred to above in connection with FIG. 5) and may beprogrammed/controlled by one or more software programs so that the VASWSP computer 1302 may provide functionality as described herein.

In some embodiments, the wallet services provided by the VAS WSPcomputer 1302 may entail maintaining one or more digital wallets peruser/subscriber for the services of the VAS WSP. In some embodiments,for example, the user 210 may have stored for his/her benefit in the VASWSP computer 1302 one or more of the following: (a) a rewards wallet,for loyalty points, coupons, promotional payments, etc.; (b) a medicalinsurance wallet for medical, dental, long term care, and other likebenefits; (c) a casualty insurance wallet; and (d) a social benefitswallet (e.g., for social welfare payments, government pension planbenefits, etc.).

FIG. 14 is a high level flow chart that illustrates a transactionprocess that may be performed in the payment system 200 a in accordancewith aspects of the present invention.

The process of FIG. 14 may, for example, be triggered by a signal thatindicates that the current transaction is eligible for split paymentbetween two or more of the user's digital wallets, such as a benefitsaccount wallet and a payment card account wallet. For example, thesignal may be a code provided by the merchant POI terminal 204 and/ormay be the identifier for the merchant that operates the merchant POIterminal 204. For example, the signal may identify the merchant as amedical services provider, for which the charges are eligible forpartial payment via a medical insurance benefit. In some embodiments,the signal may be received to trigger the process of FIG. 14 at thePSP/acquirer computer 206 a.

At block 1402 in FIG. 14, the PSP/acquirer computer 206 a selects anappropriate benefits wallet or other digital wallet for the user 210 inresponse to the triggering signal referred to above. For example, thePSP/acquirer computer 206 a may select the user's digital wallet that isappropriate in view of the triggering signal. (For example, thetriggering signal may indicate to the PSP/acquirer computer 206 a thatthe merchant is a service provider whose services are eligible forbenefits payments. The PSP/acquirer computer 206 a may also look up theuser (via the URI for the server function in the payment-enabled mobiledevice 202) to determine that the user is eligible for benefits and hasa wallet service provider for the benefits.)

Accordingly, the PSP/acquirer computer 206 a may then contact the walletservice provider that maintains the selected wallet, assumed in thiscase to be the operator of the VAS WSP computer 1302. Thus, thePSP/acquirer computer 206 a transmits a request to the VAS WSP computer1302 to download wallet form data for the selected wallet.

The process of FIG. 14 advances from block 1402 to block 1404. At block1404, the user 210 is permitted to select a funding account from theselected digital wallet. For that purpose, corresponding wallet formdata provided by the VAS WSP computer 1302 is transmitted to thepayment-enabled mobile device 202. (For example, the wallet form datamay be received by the WSP computer 208 directly or indirectly from theVAS WSP computer 1302 and then relayed on from the WSP computer 208 tothe payment-enabled mobile device 202. In some embodiments, the VAS WSPcomputer 1302 transmits the wallet form data to the PSP/acquirercomputer 206 a, which relays the wallet form data to the WSP computer208, along with the URI for the server function in the payment-enabledmobile device 202. The WSP computer 208 may then form a securecommunication channel with the payment-enabled mobile device 202, in themanner described above in connection with block 120 of FIG. 11.) Thewallet form data, when received by the payment-enabled mobile device202, provides to the user 210 at least one funding account option thatis available to the user 210 and represented in the digital walletselected at block 1402. In some embodiments, the selected digital walletmay contain only one funding account option (e.g., a medical insurancebenefits account), and the user selection of that funding account optionmay occur simply by the user 210 indicating that he/she wishes thefunding account in question be applied to a first portion of thetransaction amount that is to be funded. In other cases, the selecteddigital wallet may contain two or more funding account options (e.g.,various loyalty points, coupons or promotion accounts available to theuser 210) and the user 210 may provide input via the payment-enabledmobile device 202 to indicate the user's selection of one of the fundingaccount options. The resulting account selection signal, indicative ofthe user's selection of an account (or confirmation that an account isto be used, if it is the only option in the selected digital wallet) maybe received by one or more of the WSP computer 208, the PSP/acquirercomputer 206 a and the VAS WSP computer 1302.

In some embodiments, the account selection signal may be transmittedfrom the payment-enabled mobile device 202 via the secure communicationchannel 222 to the WSP computer 208. The WSP computer 208 may relay theaccount selection signal to the PSP/acquirer computer 206 a, which inturn transmits the account selection signal to the VAS WSP computer1302.

Then, at block 1406 in FIG. 14, the required payment for the currenttransaction is split. FIG. 15 schematically illustrates one exampleprocess by which the payment split may take place. (This process may beperformed, for example, by the VAS WSP computer 1302.) In FIG. 15, block1502 represents a benefit computation method that may be applicable tothe funding account selected at 1404.

The benefit computation method block 1502 may receive as an input (asindicated at 1504) the total amount that is to be paid for the currenttransaction (i.e., the transaction amount). The output (referencenumeral 1506) from the benefit computation method block 1502 may be themaximum amount that the transaction is eligible to receive in fundingfrom the selected funding account. At a node indicated by referencenumeral 1508, an input 1510 may be received to indicate the user'spreference that less than the entire available benefit be drawn from theselected funding account. (That is, the process of FIG. 15 gives theuser 210 an option to elect to use less than the entire benefit forwhich he/she is eligible for the current transaction; information may bepresented to the user 210 concerning this option via the payment-enabledmobile device 202, and the payment-enabled mobile device 202 may receiveinput from the user 210 to indicate that the user elects to receive themaximum benefit available, or to indicate a smaller amount of thebenefit that the user 210 opts to apply to the current transaction. Thecommunications to support the user input may run between the VAS WSPcomputer 1302 and the payment-enabled mobile device 202, via thePSP/acquirer computer 206 a and the WSP computer 208.) The output 1512from the node 1508 is the smaller amount of the inputs 1506 and 1510,and becomes the amount to be funded for the current transaction from theselected funding account. The feedback path indicated at 1514 representsupdating (reduction) of the available balance in the selected fundingaccount.

A consequence of the process of FIG. 15 is that a partial transactionamount is determined, which partial transaction amount is funded fromthe funding account option selected (or confirmed) by the user 210 atblock 1404. Block 1408 in FIG. 14 represents the partial funding of thetransaction amount, by the amount output from node 1508 in FIG. 15, fromthe funding account selected at block 1404.

Following block 1408 in FIG. 14 is block 1410. At block 1410, anotherone of the user's digital wallets may be selected by the PSP/acquirercomputer 206 a. For example, the PSP/acquirer computer 206 a may nextselect the user's digital wallet maintained at the WSP computer 208.

With the second digital wallet having been selected, the process of FIG.14 advances to block 1412. At block 1412, the user 210 is permitted toselect a funding account from the second digital wallet that wasselected. To allow the user to select the next funding account, walletform data that corresponds to the second selected digital wallet istransmitted to the payment-enabled mobile device 202. The latter walletform data, when received by the payment-enabled mobile device 202,provides to the user 210 at least one, and possibly two or more, fundingaccount options that are available to the user and are represented bythe second selected digital wallet (i.e., the digital wallet selected atblock 1410). Assuming that two or more funding account options (say, twoor more payment card accounts) are represented in the second selecteddigital wallet, the user interface of the payment-enabled mobile device202 may present those options to the user 210, and may receive inputfrom the user 210 to indicate the user's selection of an account fromamong those options. The resulting account selection signal, includingdata indicative of the user's selection of the latter account, may bereceived by one or more of the WSP computer 208, the PSP/acquirercomputer 206 a and the VAS WSP computer 1302. In some embodiments, ifthe second selected wallet was maintained by the WSP computer 208, thebalance of the operation corresponding to block 1412 may includeoperations such as those described above in connection with blocks 1130,1132, 1134, 1136 and 1138 in FIG. 11B, resulting in funding of thebalance of the transaction amount (block 1414, FIG. 14) from a paymentcard account selected by the user 210 at block 1412.

In the above discussion of FIG. 14, it was stated that the PSP/acquirercomputer 206 a handled selection of a first one of the user's digitalwallets and thereafter a second one of the user's digital wallets.Alternatively, however, in some embodiments another entity in thepayment system 200 a may perform one or both of the wallet selections.For example, the user 210 may make one or both of the wallet selections,possibly with guidance from the PSP/acquirer computer 206 a via acommunication path running through the WSP computer 208 to thepayment-enabled mobile device 202.

As noted above (e.g., in connection with discussion of block 1124 inFIG. 11B and/or the discussion of the wallet selection applicationprogram 904 in relation to

FIG. 9), the user's selection of an account (e.g., a payment cardaccount) from the user's digital wallet may be accompanied by arequirement that the user participate in a CVM operation. FIG. 16schematically illustrates a biometric-based cardholder verificationmethod (CVM) that may be performed according to aspects of the inventionin the payment systems 200 or 200 a of FIG. 2 or FIG. 13.

In FIG. 16, components to the left of dividing line 1602 may be part ofthe payment-enabled mobile device 202 shown in FIG. 2, while componentsto the right of the dividing line 1602 may be part of the WSP computer208. In this arrangement, the payment-enabled mobile device 202 mayserve as a proving device, and WSP computer 208 may serve as a verifyingdevice, for the biometric CVM operation. For example, as part of thepayment-enabled mobile device 202 there may be a biometric sensor 1604and a data acquisition unit 1606. (In some embodiments, the biometricsensor may be constituted by the microphone 320 (FIG. 3) or a camera(not shown) included in the payment-enabled mobile device 202.) Thepayment-enabled mobile device 202 may perform the relatively limitedfunction of acquiring the raw biometric data and sending it to the WSPcomputer 208 via the communication channel 222. In this embodiment, thepayment-enabled mobile device 202 need not store any biometric referencedata, and accordingly need not be personalized for biometric CVM. Thismay tend to reduce or eliminate the need for a large permanent memory inthe payment-enabled mobile device 202. It is also advantageous that thecryptographically secured communication channel 222 is available betweenthe payment-enabled mobile device 202 and the WSP computer 208 to allowfor transmission of the raw biometric data from the former device to thelatter device.

The reference data for the biometric CVM, in this embodiment, may bestored at the WSP computer 208, as indicated by block 1608 in FIG. 16.Processing of the raw biometric data received by the WSP computer 208from the payment-enabled mobile device 202 may be performed byfunctional blocks such as feature extraction block 1610, image signalprocessing block 1612 and comparison/matching block 1614. A decisionfunction 1616 on the WSP computer side may determine whether the CVM isvalid based on output from the comparison/matching block 1614 and basedon previously stored decision parameters indicated at 1618 in FIG. 16.

Assuming that the decision parameters are satisfied, the output from thedecision function 1616 may be authorization of the transaction, asindicated at 1620.

With the arrangement shown in FIG. 16, biometric data captured by thepayment-enabled mobile device 202 is not analyzed at the payment-enabledmobile device 202, but rather un-analyzed biometric data is transmittedfrom the payment-enabled mobile device 202 to be received by the WSPcomputer 208, and to be analyzed and verified at the WSP computer 208.This arrangement may result in a high degree of flexibility in terms ofpermitting various different types of biometric CVM to be employed fordifferent accounts in the user's digital wallet, and/or for new types ofbiometric CVM to be introduced into the operations of the payment system200 a. The flexibility available for applying different types ofbiometric CVM may also be utilized to match the type of biometric CVMcapability supported by the particular mobile device to be used in thetransaction. Also, since the WSP computer 208 is highly secure, it isquite unlikely that the user's biometric reference data would becompromised, as could more easily occur if the biometric reference datawere present in the payment-enabled mobile device 202 and the latterwere lost or stolen.

FIG. 17 is a block diagram that illustrates aspects of thebiometric-based CVM of FIG. 16. In addition, FIG. 17 may aid inillustrating how a biometric-based CVM as in FIG. 16 may be integratedinto the transaction process described above primarily with reference toFIGS. 2, 11A and 11B.

FIG. 17 may be considered to represent a subset of the apparatus of FIG.2, as modified to accommodate a biometric CVM process as described abovein connection with FIG. 16. FIG. 17 shows the following features shownin and discussed above in connection with FIG. 2—the payment-enabledmobile device 202, the WSP computer 208, and the communication channel222. Further, as part of the payment-enabled mobile device 202, FIG. 17also shows the following software elements that were discussed above inconnection with FIG. 7—the consumer device server function 702 and thewallet selection application 708. Still further, and also as part of thepayment-enabled mobile device 202, FIG. 17 shows the components 1604,1606 (biometric sensor and biometric data acquisition) referred to inthe above discussion of FIG. 16.

Also, biometric verification block 1702 in FIG. 17, which is shown aspart of the WSP computer 208, represents the functional blocks shown inFIG. 16 to the right of dividing line 1602. Also seen in FIG. 17, aspart of the WSP computer 208 is the transaction concentrator block 214referred to above in connection with FIG. 2. In the apparatus asillustrated in FIG. 17, the transaction concentrator block 214 is shownas being in communication with the biometric verification block 1702 ofthe WSP computer 208.

In operation of the apparatus of FIG. 17 (and also referring to blocks1124, 1126 and 1128 of FIG. 11B), the user 210 may perform accountselection via the wallet selection application 708, and may presenthis/her biometric feature to the biometric sensor 1604. Afteracquisition of the user's biometric data, the latter istransmitted—together with a biometric technology identifier (e.g.,fingerprint, voice recognition, finger vein, retina, facial geometry,etc.) to the wallet selection application 708. After gathering theuser's account selection, the biometry identifier and the raw biometricdata, the wallet selection application 708 sends them via the consumerdevice server function 702 and the secure channel 222 to the WSPcomputer 208.

Based on the biometry identifier, the WSP computer 208 chooses theappropriate biometric data processing algorithm for the raw biometricdata and the appropriate stored biometric reference data repository.Within the selected biometric data repository, the particular set ofbiometric reference data for the user in question may be retrieved basedon the URI for the consumer device server function 702 in thepayment-enabled mobile device 202. The biometric verification block 1702then applies the biometric verification process illustrated in FIG. 16to the raw data. Assuming the result of the process is, “valid”, thenthe transaction concentrator block 214 may trigger the authorizationrequest(s) as referred to above in connection with block 1130 of FIG.11B.

FIG. 18 is a block diagram that illustrates an alternative CVM that maybe performed according to aspects of the invention.

FIG. 18 may aid in illustrating a CVM that may be particularly suitablefor use in remote (e-commerce) transactions, although it may also beuseful for an in-store transaction that is not consummated via a localPOS terminal FIG. 18 shows a modified version (reference numeral 208 a)of the WSP computer referred to above. The WSP computer 208 a mayinclude an interactive voice response (IVR) unit 1802, a voicerecognition unit 1804, a wallet partition unit 1806 and a paymentgateway function 1808. The WSP computer 208 a may interact with acell-phone 1810 via the IVR unit 1802 and the voice recognition unit1804. The cell-phone 1810 may or may not be a smartphone, and may or maynot be a payment-enabled mobile device (such as described hereinabove).The WSP computer 208 a may also interact with a conventional browser1812 via the payment gateway function 1808. (The browser 1812 may run ona conventional personal computer, tablet, smartphone or the like, whichare not separately shown. The browser 1812 may receive input from thesame individual (not shown) who owns and uses the cell-phone 1810. Thebrowser may be configured so that it “knows” the telephone number forthe cell-phone 1810.)

In operation of the apparatus of FIG. 18, the browser 1812 may retrievean ordering page from the merchant e-commerce site (not shown), and mayallow the user to select one or more items for purchase, as indicatedvia the browser to the e-commerce site. The e-commerce site may thencompute the amount due for the transaction and submit the transactionamount to the browser. The browser may then send the transaction amount,the cell-phone telephone number and possibly other transactioninformation as well to the payment gateway function 1808 of the WSPcomputer 208 a.

Using the cell-phone telephone number, the payment gateway function 1808retrieves the digital wallet for the user from the wallet partition unit1806, and from the user's digital wallet the WSP computer 208 agenerates wallet form data, which is supplied to the IVR unit 1802together with the cell-phone telephone number. The IVR unit 1802 callsthe cell-phone 1810 and audibly prompts the user to make an accountselection based on the wallet form data. The user responds by spokenutterance into the cell-phone 1810 to indicate his/her payment cardaccount selection. The voice utterance is sent from the cell-phone 1810to the voice recognition unit 1804 of the WSP computer 208 a. The voicerecognition unit performs both of the following on the basis of thevoice utterance—(a) identifying the user based on a voice samplereference previously stored in a reference data repository on the WSPcomputer 208 a (where the reference was associated with the cell-phonetelephone number)—i.e., in effect CVM; and (b) detecting the user'sselection of a payment card account from the user's digital wallet basedon speech content recognition as applied to the voice utterance receivedfrom the cell-phone 1810. If the CVM is found “valid”, then the accountselection is passed on to a wallet unit in the WSP computer 208 a. Thewallet unit then triggers an authorization request for the selectedpayment card account (or more than one authorization request, if theuser elected to split payment among two or more of his/her payment cardaccounts). The WSP computer 208 a then receives an authorizationresponse from the payment card account issuer (or more than one, if morethan one account is being used). The result of the authorizationresponse is provided to the payment gateway function 1808 of the WSPcomputer 208 a. If the transaction is approved, the payment gatewayprovides an acknowledgment message accordingly to the merchante-commerce site, such that the transaction is successfully concluded.

Returning the discussion now to the payment-enabled mobile device 202,it has been noted above that in some embodiments the device 202 may bephysically constituted by smartphone hardware. Alternatively, however,the device 202 may be an IC card of the type that includes a display andkeyboard. In such a case, for example, the device 202 may communicatewith the WSP computer 202 via the POI terminal In still otherembodiments, the IC card need not have a keyboard or display. The ICcard, which may be a contactless card or a contact card, may be incommunication with the POI terminal, which may provide a user interfacefor the card and for selection of wallet account(s).

As used herein and in the appended claims, the term “computer” should beunderstood to encompass a single computer or two or more computers incommunication with each other.

As used herein and in the appended claims, the term “processor” shouldbe understood to encompass a single processor or two or more processorsin communication with each other.

As used herein and in the appended claims, the term “memory” should beunderstood to encompass a single memory or storage device or two or morememories or storage devices.

The flow charts and descriptions thereof herein should not be understoodto prescribe a fixed order of performing the method steps describedtherein. Rather the method steps may be performed in any order that ispracticable.

As used herein and in the appended claims, the term “payment card systemaccount” includes a credit card account or a deposit account that theaccount holder may access using a debit card. The terms “payment cardsystem account” and “payment card account” are used interchangeablyherein. The term “payment card account number” includes a number thatidentifies a payment card system account or a number carried by apayment card, or a number that is used to route a transaction in apayment system that handles debit card and/or credit card transactions.The term “payment card” includes a credit card or a debit card.

As used herein and in the appended claims, the term “payment cardsystem” refers to a system for handling purchase transactions andrelated transactions. An example of such a system is the one operated byMasterCard International Incorporated, the assignee of the presentdisclosure. In some embodiments, the term “payment card system” may belimited to systems in which member financial institutions issue paymentcard accounts to individuals, businesses and/or other organizations.

Although the present invention has been described in connection withspecific exemplary embodiments, it should be understood that variouschanges, substitutions, and alterations apparent to those skilled in theart can be made to the disclosed embodiments without departing from thespirit and scope of the invention as set forth in the appended claims.

What is claimed is:
 1. A method comprising: receiving a first message ata wallet service provider computer, the first message including (a)transaction detail data indicative of a transaction originated at apoint of interaction (POI) device, and (b) transaction context data forthe transaction; receiving a second message at the wallet serviceprovider computer, the second message including (i) a copy of thetransaction detail data, and (ii) a copy of the transaction contextdata; verifying, by the wallet service provider computer, that the copyof the transaction detail data matches the transaction detail dataincluded in the first message and that the copy of the transactioncontext data matches the transaction context data included in the firstmessage.
 2. The method of claim 1, wherein the wallet service providercomputer receives the second message via a cryptographically-securedinternet communication channel between the wallet service providercomputer and a server function present in a payment-enabled mobiledevice.
 3. The method of claim 2, wherein the wallet service providercomputer receives the first message from an acquirer financialinstitution.
 4. The method of claim 2, wherein the wallet serviceprovider computer receives the first message from a merchant thatoperates the POI device.
 5. The method of claim 1, wherein: thetransaction detail data includes a transaction amount and a transactiondate, and the transaction context data includes (x) merchantidentification data for identifying a merchant that operates the POIdevice; (y) location data for identifying a location of the POI device;and (z) a unique transaction number generated for the transaction by thePOI device.
 6. The method of claim 5, wherein the first message includesdevice address data that indicates an internet address for said serverfunction present in the payment-enabled mobile device.
 7. Anon-transitory medium having program instructions stored thereon, themedium comprising: an interception application software program forproviding a server function for receiving service requests from a remotedevice; and a contact exchange application software program for (a)exchanging communications with the interception application softwareprogram, and (b) providing contact data to a device in proximity to themedium, the contact data including (i) data that identifies a walletservice provider, and (ii) data that represents an internet address forthe interception application software program.
 8. The medium of claim 7,further comprising: a wallet selection application program for (x)exchanging communications with the interception application softwareprogram, and (y) receiving input from a user to select a payment cardaccount from among a plurality of payment card accounts represented in adigital wallet maintained for the user by the wallet service provider.9. The method of claim 8, wherein the remote device is a computeroperated by the wallet service provider.
 10. The medium of claim 9,wherein the wallet selection application software program is configuredto receive from the remote device, via the interception applicationsoftware program, data that represents said plurality of payment cardaccounts.
 11. The medium of claim 10, wherein the interceptionapplication software program is configured to generate and transmit tothe remote device a message authentication code based at least in parton (a) said user input for payment card account selection, (b)transaction data received from the device in proximity to the medium,and (c) transaction context data received from the device in proximityto the medium.
 12. The medium of claim 11, wherein the contact exchangeapplication software program is configured to receive the transactiondata and the transaction context data and to provide the transactiondata and the transaction context data to the interception applicationsoftware program for forwarding to the remote device.
 13. The medium ofclaim 12, wherein the medium is part of a mobile device.
 14. The mediumof claim 13, wherein the device in proximity to the medium is a point ofinteraction (POI) device that is in proximity to the mobile device. 15.The method of claim 14, wherein the contact exchange applicationsoftware program is operative to select a mode of communication betweenthe mobile device and the POI device.
 16. The method of claim 13,wherein the wallet selection application program is operative to requirea user of the mobile device to perform a cardholder verification method(CVM).
 17. A method comprising: receiving, in a pool account computeroperated by a wallet service provider, payment network clearing creditsfrom payment card accounts; and distributing the payment networkclearing credits, from the pool account computer, among a plurality ofacquirer financial institutions, the distributed credits for furtherdistribution from the acquirer financial institutions to merchants thataccepted the payment card accounts.
 18. The method of claim 17, whereinthe receiving step includes receiving the credits from issuers of thepayment card accounts via at least one payment network clearing account.19. The method of claim 17, wherein the payment card accounts include: afirst plurality of payment card accounts issued in connection with afirst payment network; and a second plurality of payment card accountsissued in connection with a second payment network that is differentfrom the first payment network.
 20. The method of claim 17, wherein thereceived payment network clearing credits correspond to payment networktransactions for which the wallet service provider requestedauthorization.
 21. An apparatus comprising: a processor; and a memory incommunication with the processor, the memory storing programinstructions, the program instructions controlling the processor toperform operations as follows: receiving a first message, the firstmessage including (a) transaction detail data indicative of atransaction originated at a point of interaction (POI) device, and (b)transaction context data for the transaction; receiving a secondmessage, the second message including (i) a copy of the transactiondetail data, and (ii) a copy of the transaction context data; andverifying that the copy of the transaction detail data matches thetransaction detail data included in the first message and that the copyof the transaction context data matches the transaction context dataincluded in the first message.
 22. The apparatus of claim 21, whereinthe second message is received via a cryptographically-secured internetcommunication channel with a server function present in apayment-enabled mobile device.
 23. The apparatus of claim 22, whereinthe first message is received from an acquirer financial institution.